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Introducing Project Long Bud: 
Internet Pilot Project for the Deployment of X.500 Directory 
Information in Support of X.400 Routing 


Status of this Memo 


This memo provides information for the Internet community. This memo 
does not specify an Internet standard of any kind. Distribution of 
this memo is unlimited. 


Abstract 


The Internet X.400 community (i.e., GO-MHS) currently lacks a 
distributed mechanism providing dynamic updating and management of 
message routing information. The IETF MHS-DS Working Group has 
specified an approach for X.400 Message Handling Systems to perform 
message routing using OSI Directory Services. The MHS-DS approach 
has been successfully tested in a number of local environments. 


This memo describes a proposed Internet Pilot Project that seeks to 


prove the MHS-DS approach on a larger scale. The results of this 
pilot will then be used to draw up recommendations for a global 
deployment. 


1. Background 


The 1988 edition of X.400 introduces, among other extensions or 
revisions, the concept of O/R Names which assumes the existence of a 
widely available Directory Service. This Directory Service is needed 
to support several MHS operations (support for names to identify 
senders and receivers of messages in a user-friendly fashion, support 
for distribution lists, authentication of MHS components, description 
of MHS components capabilities...). 


The prime advantage of Directory Names, as perceived by many users, 


was to release users from the remembering of complex O/R Addresses 
for their correspondents. 
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In the MHS infrastructure, as compared to other protocols, a name by 
itself does not contain enough information to allow the Message 
Transfer Agents (MTAs) to route a message to the User Agent (UA) 
servicing this name. The routing process is based on information 
provided by different MHS Management Domains, whether they are public 
or private. 


An MHS community combines several administrative MHS domains among 
which agreements for cooperative routing exist: the GO-MHS community 
is the set of MTA’s taking care of X.400 mail operations on the 
Internet [RFC 1649]. 


In the absence of a distributed Directory Service, an interim 
technique has been developed within the GO-MHS community to collect 
and advertise routing information. This resulted in an experimental 
IETF protocol [RFC 1465]. 


2. Rationale 


A number of routing problems are preventing the present Internet 
X.400 service from expanding its number of participating message 
transfer agents to a global scale. The two most critical problems 
are: 


* The present mechanism of centrally maintained and advertized 
MTA routing tables has been optimized as far as possible. 
Increasing the number of directly connected MTAs increases also 


the workload on the MHS managers. The current solution does 
not scale. Routing must be a fully dynamic and distributed 
process. 


* Manual propagation and installation of routing tables do not 
guarantee consistency of routing information (even in a loose 
fashion) when it is accessed by different MTAs scattered across 
the globe. 


It is commonly accepted that a distributed mechanism providing for 
dynamic updating and management of X.400 routing information is 
highly desirable. The focus of the project is to establish X.500- 
based support of X.400 routing, at a very large scale. 


3. Benefits 


Using the Directory as a dynamic means of information storage and 
advertisement will guarantee participants in Project Long Bud that 
their updated data are globally available to the community. Asa 
direct consequence of the above, a participating MHS manager will be 
released from configuring connections to the other participants. 
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Directory-capable MTAs will be able to discover more optimal and more 
direct routes to X.400 destinations than are practical today. This 
will enable faster delivery of messages. 


The infrastructure reliability will be improved: the information 
stored in the Directory will allow automatic use of backup 
connections in case of remote MTA or network problems. X.400 mail 
managers in the GO-MHS Community should then be released from the 
need to know the complexity of the whole mail routing infrastructure. 
Providing a dynamic routing infrastructure will eliminate 
inconsistencies introduced by unsynchronized static tables and 
improve quality of service. 


Furthermore, besides the robustness and the optimization of the new 
routing infrastructure, the Long Bud approach should bring to the 
participating organizations better control over how they establish 
and maintain their interconnection with the GO-MHS community. 


Participants will share in building an X.400 network which can expand 
to a very large scale. They will develop experience using a global 
messaging architecture which scales well and requires minimal 
administrative overhead. They will be able to discuss experience 
with the MHS-DS experts and architects in the ongoing standards 
development cycle. 


4. Definition of project LONG BUD 


The Long Bud pilot wishes to demonstrate that the X.500 Directory is 
able to provide a global-scale service to messaging applications. 


Although MHS-DS provides ways to use private routing trees, Long Bud 
will focus on the Open Community Routing Tree as used by the GO-MHS 
community. 


4.1 Project Goals 

Project Long Bud has the following goals: 

* Gather pilot experience of the defined framework for X.500 
support of MTA routing, as defined by the IETF MHS-DS Working 
Group [Kille 94]. 

* Actively investigate migration of the existing operational 
X.400 service from a routing method based upon distribution of 


centrally maintained static tables, as specified in [RFC 1465], 
to a method based instead upon X.500: 
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-- Deploy X.400 MTAs which are directly capable of reading 
routing information from the X.500 Directory, in 
compliance with the specifications of the MHS-DS Working 
Group. This type of MTA is called a directory-capable 
MTA. 


-- Deploy tools which read routing information from the X.500 
Directory and use it to generate static routing tables for 
MTAs which are not directory-capable. 


* specify a set of minimal operational requirements needed before 
X.500-based routing of X.400 messages can be widely deployed. 


4.2 Phasing 


The first phase of Project Long Bud consists in deploying a small 
number of directory-capable MTAs operated by members of the MHS-DS 
Working Group and GO-MHS community. These MTAs must be capable of 
using information in the X.500 directory to route messages to all 
other members of the project as well as to the existing GO-MHS 
community. As of this writing, an initial set of MTAs is already 
operational. 


At the end of this phase, the following goals should be achieved: 


* The X.500 DIT must be populated with enough routing information 
to allow the participating MTAs to route reliably messages to 
each other and to the existing GO-MHS community. 


* The X.500 DSAs holding the routing information must operate at 
a quality of service that is acceptable for an operational 
X.400 service. 


As a prerequisite, a sufficient number of MTA managers must be 
willing to participate in Project Long Bud for the first set of 
results to be significant. Support for a protocol stack conforming 
to [RFC 1006] is mandatory. All MTAs participating in the Long Bud 
pilot need to register in the Open Tree and must be prepared to 
accept connections from anyone. 


Note that in the first phase, default routes will be established in 
the DIT such that messages addressed to destinations outside of the 
Long Bud community will be routed to designated MTAs in the GO-MHS 
community. This will allow for full connectivity between the Long 
Bud community and the GO-MHS community which are related, but 
distinct communities. Interworking between these two must be 
established and coordinated. 
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In the second phase of Project Long Bud, a greater number of MTAs 
should be added to the experiment. Cooperation with non directory- 
capable communities must be addressed. 


4.3 General Approach 


No large scale resources have been committed to this project. Yet, 
expedient deployment is desirable. Therefore, the pilot project 
needs to be focused and relatively short-lived. The general approach 
for satisfying these requirements includes: 


* Use as many existing MHS-DS tools as possible. Also, continue 
to track the progress of tools being developed by project 
members and facilitate their deployment as soon as they are 
ready. 


* Coordinate efforts with existing GO-MHS community service. 


* Establish a core infrastructure: 4 DSAs (two in the United 
States and two in Europe) are set up to serve MHS-DS 
information. 


* Wherever it is technically feasable, DSA managers will 
establish bilateral agreements with one (or more) of the core 
DSAs in order to duplicate their routing information. For 
example, the core DSAs support the replication protocol 
specified in [RFC 1275] as a duplication technique. 


* the Long Bud pilot needs to cooperate actively with DANTE 
NameFlow (the continuation of the PARADISE Pilot) and other 
directory providers in order to promote stability and 
consistency of informations. 


4.4 Tools Needed 


To facilitate widespread deployment of MHS-DS routing technology and 
to foster interworking between directory-capable MTAs and MTAs which 
are not directory-capable, tools providing the following 
functionalities need to be developed: 


populate the Directory with routing information: such a tool must 
accept routing information specified in the standard syntax 
used by the GO-MHS community (see [RFC 1465]) as input, and it 
will load or update entries which convey the same information 
in the X.500 Directory. 
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downloading of routing information from the Directory: in order to 
provide a migration path for organizations not using 
directory-capable MTAs, a tool is needed which will read X.400 
routing information from the X.500 Directory and generate 
static routing information from it. The syntax of the static 
information generated will conform to the syntax defined by the 
GO-MHS community, so that "classical" MTAs run as they 
currently do. 


displaying route taken by a message between two end-points: this 
tool should accept two parameters as input: the X.500 
distinguished name of an MTA, and an X.400 O/R name. It will 
display the possible routes which may be taken in order to 
deliver a message from the specified MTA to the specified X.400 
destination. This tool looks very much the same as the 
traceroute facility used at the IP level. 


These tools must use standard protocols to access the Directory (such 
as DAP [CCITT 88] or LDAP [RFC 1487]). Portability is encouraged. 


A note on quality 


Pilot use of this Directory information depends heavily on data 
quality and availability. Although the administration of DSA 
availability and global Directory data accuracy are not in the scope 
of Long Bud, care must be taken that Directory resources used by Long 
Bud participants are administrated well. 


If they have the technical ability to do so, Long Bud participants 
are encouraged to replicate routing information in their Directory to 
improve data availability. 


Directory data used by the pilot must be accurate: solutions to this 
problem will be recommanded as the project matures. 


5. Participation Guide 


The existing operational X.400 service, the GO-MHS service, uses the 
following method to distribute and manage X.400 routing information: 
A group of MTAs is organized into a routing community. The community 
keeps its routing information up to date by assigning to each MTA 
manager the responsibility of determining the routing information for 
his/her MTA, formalizing this routing information in the syntax 
defined by the community and sending the result to the GO-MHS 
coordination service. Once the information has been validated 
against the other data provided by all managers in the community, the 
coordination service will advertise it to the whole community. Each 
manager will then have to update his/her MTA configuration with the 
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verified information. 
The purpose of Project Long Bud is to allow a manager to operate an 
MTA without having to perform ANY manual steps when another MTA 
manager adds new or changes existing routing information. This will 
facilitate efficient, dynamic, and manageable interconnection of very 
large communities of MTAs. It will allow the Internet X.400 
community to overcome the limitations in scalability which it is 
currently encountering. 

5.1 Prerequisites for participation 


The prerequisites for joining Project Long Bud are: 


Step 1: Participants in the pilot must have a good knowledge of 
the IETF MHS-DS Working Group activities and documents: 


1. Participants must join the MHS-DS distribution list: 
RFC-822: mhs-ds@mercury.udev.cdc.com 


X.400: PN=mhs-ds; OU=mercury; OU=OSS; 
OU=ARH; O=CPG; P=CDC; A=ATTMail; C=US 


Requests to join the MHS-DS distribution list may be sent 
to the following email address: 


RFC-822: mhs-—ds-request@mercury.udev.cdc.com 
X.400:  PN=mhs-ds-request; OU=mercury; OU=OSS; 


OU=ARH; O=CPG; P=CDC; A=ATTMail; C=US 


2. Participants must retrieve and become familiar with all 
relevant tools and documents stored on the Project Long 
Bud anonymous FTP server 

Host name: ftp.css.cdc.com 


Directory: pub/mhs-ds/long-bud 


In particular, openly available software related to Long 
Bud activities will be kept up-to-date at this location. 
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3. If not already done, participants must do one of the 
following: 


* Upgrade their X.400 and X.500 software such that it 
supports the MHS-DS specifications as in [Kille 94]. 


* Use the tools which extract MHS-DS information from 
the directory and generate whatever local 
configuration files are necessary to allow local MTA’s 
to use the information. This should be done 
frequently (at least once per day). 


Step 2: Participants must register required entries in the 
Directory so that their MTA(s) is (are) known to the 
Directory. 


1. Arrange with the appropriate DSA Manager (who can be a 
local manager if the DSA is run by the participating 
organization, or a manager who is in charge of running the 
organization’s DSA) to create an entry for the local 
MTA(s) involved in the pilot. At this stage, only 
connection information is required. 


2. Check, test and verify the connection information with at 
least one other participant. The mhs-ds distribution list 
should be used for announcing the new registration and 
asking volunteers for testing. 


3. Participants must establish sensible default X.400 routes 
to existing GO-MHS destinations for which X.500-based 
routing information will not exist initially. 


Step 3: Participants can then enter their routing information in 
the Directory. 


1. Before any routing is entered in the DIT, participants 
must check with the GO-MHS Coordination Service that the 
routes they want to register can be properly handled by 
the GO-MHS community (contact information is 
mailflow@mailflow.dante.net). It is crucial for the Pilot 
that any routing information entered in the Directory is 
kept carefully accurate if the experiment is to be 
meaningful. Participants may also consider the need for 
mapping rules (see [RFC 1465] for details). 


2. Once the above step is validated by the GO-MHS 


Coordination Service, participants must record routing 
information for their MTA(s) in the Internet X.500 
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directory service. This requires that a participant does 
the following: 


* Arrange with the appropriate DSA Manager (who can be 
either a local manager if the DSA is run by the 
participating organization or a manager which is in 
charge of running the organization’s DSA) to enter 
X.400 routing information in a routing tree held by 
the participating organization. This routing tree 
should contain all necessary information for the local 
mail domain. 


* Check, test and verify the registered routing 
information with at least one other participant. The 
mhs-ds distribution list should be used for announcing 
the new registration and asking volunteers for 
testing. 


3. If a participant adds new nonleaf entries to the Open 
Community Routing Tree, then s/he must find at least one 
other participant who will maintain a slave copy of the 
children of the nonleaf entry. Send email to the mhs-ds 
distribution list in order to find a partner who is 
willing to do this. 


4. If a participant adds new nonleaf ADMD or PRMD entries to 
the directory, then s/he must contact the managers of the 
Long Bud core DSA’s and arrange to provide slave copies of 
the children of the ADMD and/or PRMD entries to all of the 
core DSA’s. Send email to the mhs-ds distribution list in 
order to contact the core DSA managers. 


5. Once the above testing is completed, send email to the 
mhs-ds distribution list announcing the establishment of 
new X.500-based routes. 


6. Notes on side effects 


The Long Bud Pilot Project, with its specific scope, is investigating 
a new direction in X.500 service usage. This should facilitate and 
expedite the global deployment of X.500 on the Internet. 


Once the routing infrastructure illustrated by the Long Bud 
experiment is in place, the routing process will be able to take into 
account additional information to improve quality of service 
(minimizing messages conversions, enforcing various security policies 
established by MHS domains, taking advantage of recipients’s 
capabilities stored in the Directory, ...). While the Open Tree 
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provides global connectivity, multiple private routing trees allow 
the use of various routing trees. 
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8. Security Considerations 
Security issues are not discussed in this memo. 
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